A method for building and evaluating formal specifications of object-oriented conceptual models of database systems

This report describes a method called MCM (Method for Conceptual Modeling) for building and evaluating formal specifications of object-oriented models of database system behavior. An important aim of MCM is to bridge the gap between formal specification and informal understanding. Building a MCM model is a process that moves from the informal to the formal, evaluating the model is a process that moves back from the formal to the informal. First, a general framework for information system development methods is given, that is used to indicate which elements are needed to build a particular information system development method. In general, the following elements are needed (see figure 0.1) l. Requirements determination methods that can be used to determine the information needs of the environment, and to find functional and nonfunctional requirements specifications. 2. Conceptual modeling methods that can be used to elaborate the statement of functional require­ ments into a formal specification of observable system behavior. 3. Implementation methods that can be used to transform the conceptual model specification into an implementation within the constraints indicated by the nonfunctional requirements. 4. Project management methods that can be used to manage the development process in the presence of limited resources and a potentially disturbing environment. MCM is a conceptual modeling method, and must therefore in any information system development project be supplemented with three other kinds of methods. MCM contains three kinds of methods (figure 0.1). 1. Observation methods to find relevant data about the required database system. 2. Induction methods that allow one to go from a finite set of data about required system behavior to a conceptual model that represents all of this behavior. 3. Evaluation methods that allow one to test the quality of a specification of a conceptual model. In this report, I concentrate on induction and evaluation methods and merely make a list of relevant observation methods. The induction methods listed in figure 0.1 are not exhaustive. MCM can be viewed as a framework within which methods and techniques for conceptual modeling can be plugged. Some of these methods and techniques are mentioned in this report but not elaborated. There are three kinds of evaluation methods, that deal with the validity of the conceptual model, the utility of the specified behavior, and the quality of the use that is made of the available modeling constructs. Prototyping and animation are briefly discussed as evaluation methods. The quality checks, however, are listed exhaustively. The result of following MCM is a conceptual model. In the philosophy of MCM, a conceptual model consists of three components (see figure 0.2): 1. The UoD model is a model of the part of reality represented by the database system. 2. The DBS model represents DBS behavior, such as the queries to be asked from the DBS, the user interface, the contents and layout of reports produced by the DBS, etc. 3. A model of the boundary between the DBS and the UoD. This is a list of all possible transactions that the DBS can engage in, plus the function that this behavior has for the user of the DBS

Role change in database domains

In data modelling the universe of discourse (UoD) is divided up into classes having a taxonomic structure which is intended to express some of the structure inherent in the UoD. Some of these classes. for example the class of persons or departments, may be called "natural kinds," in that they are a fixed set of possible objects, existing in some possible state of the UoD, and all of which have a similar structure and behavior. Others have a more dynamic nature, such as the class of stu­ dents. Whereas an object is created as as person and, when it ceases to be a person, ceases to exist, an object may come to be a student and cease to be one without com­ ing into existence or passing away. A class like persons is a natural kind, and a class like students will be called roles in this report. This report studies the formal defini­ tion of roles and the resulting taxonomy of natural kinds and roles

Subsystem Design Guidelines for Extensible General-Purpose Software

We discuss subsystem design for extensible general-purpose information systems.We ex-tract guidelines from a case study of the redes-ign and extension of an advanced workflow management system and place them into the context of existing software engineering re-search. Key aspect is the distinction between essential and physical architectures, related to software clustering and distribution. 1.1 Keywords Architecture design, subsystem design, general-purpose software 2

RE'03: Practical Requirements Engineering Solutions

Introduction to a special issue on the IEEE Requiurements Engineering Conference 200

Towards Validating Risk Indicators Based on Measurement Theory

Due to the lack of quantitative information and for cost-efficiency purpose, most risk assessment methods use partially ordered values (e.g. high, medium, low) as risk indicators. In practice it is common to validate risk scales by asking stakeholders whether they make sense. This way of validation is subjective, thus error prone. If the metrics are wrong (not meaningful), then they may lead system owners to distribute security investments inefficiently. Therefore, when validating risk assessment methods it is important to validate the meaningfulness of the risk scales that they use. In this paper we investigate how to validate the meaningfulness of risk indicators based on measurement theory. Furthermore, to analyze the applicability of measurement theory to risk indicators, we analyze the indicators used by a particular risk assessment method specially developed for assessing confidentiality risks in networks of organizations